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Application engineering 


In this section, applications that have significant capacity impact and require 
engineering are addressed. Suggestions are given for engineering the 
application for proper operation from a capacity perspective. 


Descriptions of features and their functionality are not given here. Please 
refer to feature documentation in the Northern Telecom Publications. 


Remote Virtual Queuing (RVQ) (available with 
X11 release 18 and later) 
Engineering parameters 


Several timers are required to control the feature functions on an originating 
switch. T2, the duration timer for the originator to accept the RVQ offer is not 
service changeable, and is set to 16 seconds. T6, the duration timer for 
ring-again at the originating switch is set at 30 minutes. The retry timer, Tx, 
is user configurable within the range of 2-30 seconds, and is set to a default 
value of 10 seconds. The retry counter determines the number of times the 
initial set should be searched before the scanning includes the extended set. It 
is service changeable and supports values in the range of 4 to 10, with a 
default value of 5. 


Real-time and signaling bandwidth usage depend on the number of retries 
required before the call is connected. The number of RVQ attempts, in turn, 
is a function of Tx, the retry counter, and the network topology/route list 
index. Considering the worst case scenario, assume that only one path is 
available. The RVQ feature cannot connect a call until the initial busy trunk 
becomes available. 
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To solve for the average number of RVQ attempts on a single blocked trunk 
group, a Markov process model is defined, assuming exponential call holding 
times and Poisson arrivals of new call attempts. Conditioned on the trunk 
being busy, the probability that the trunk will still be busy after Tx seconds 
can be found by numerically solving a system of differential equations. If, 
after Tx seconds, the call is still blocked, the cycle repeats, so the number of 
attempts has a geometric distribution with the parameter being the probability 
of connection after Tx seconds. The average holding time of a trunk call, once 
it is connected, is 180 seconds. To calculate the arrival rate of call attempts 
into a trunk, use the relationship 


calls x holding time _ 
S CCS. 

The holding time used in this calculation should take into account destination 
busy or trunk busy calls, so the holding time is adjusted to 150 seconds. The 
busy hour trunk loading of 28 CCS results in an arrival rate of 18.67 calls/hr 
into a single trunk. 
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For default values Tx = 10 seconds and trunk group size (TGS) 71, the trunk 
group becomes available after an average of 1.36 RVQ attempts (RVQA), 
including the final successful attempt. If system parameters deviate 
significantly from the default values, a more accurate value for the average 
number of RVQ attempts can be found in Table 52 which assumes the North 
American T1 standard for which TGS = (24 x TL) — 1. The rows represent 
values for Tx while the columns give the number of T1 links which make up 
the trunk group. The intersection of the appropriate row and column provides 
the corresponding number of RVQ attempts. 


Table 52 
Average number of attempts for the number of T1 links in the trunk group 


Number of T1 links 
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From the RVQA numbers shown in Table 52, it can be seen that the minimum 
retry counter value, 4, is high enough that searching the extended set of trunks 
has little or no effect on average system performance except in the case of TL 
= | and Tx = 2, since the average number of retries is less than the retry 
counter value. 


Another parameter which is not defined as part of the RVQ feature, but which 
may have a significant effect on overall system performance is the percentage 
of customers that have RVQ privileges (PRVQP). Let the default value be 
100 percent. 


Real-time: 


For a given switch in a telecommunications network, let / be the average 
length of the path required to connect trunk calls originating from the switch, 
where length refers to the number of hops in the path, or, equivalently, the 
number of tandem trunk groups traversed by a given call. Assume a single 
path between originating switch and destination switch. Also, assume that 
customers accept RVQ offers and do not cancel. These assumptions provide 
worst case estimates. At each trunk group, the probability of blocking (TGB) 
is assumed to be 0.1. This value is appropriate for private networks which are 
most likely to invoke the RVQ feature. The average probability of blocking 
for an outgoing trunk call is given by (1 — (1 — 0.1)) or (1 - 0.9). If the call 
is blocked, there must be a minimum of one trunk group along the path that 
is busy. Choose any busy trunk group. For default values TGS = 71 and Tx = 
10, an average of 1.36 RVQ attempts (RVQA) will be required before that 
particular trunk group becomes available. Call this the inner loop, with an 
average duration of 1.36 cycles. Once the trunk group which was busy 
becomes available, however, at least one other trunk group along the path 


may be busy with probability (1 — 0.91), Define the external loop such that 
each cycle has a different busy trunk group, compared to the previous cycle. 
During each cycle of the external loop, an inner loop is required before the 

busy trunk group becomes available. Assuming a geometric distribution, an 


average of 1 / 0.9%! cycles will be made before exiting the external loop. 
Thus, once a call encounters a busy trunk group, the average total number of 
RVQ attempts required before a call is connected is given by the average 
number of cycles around the external loop multiplied by the average number 


of cycles around the inner loop for (1.36 / 0.971) total RVQ attempts 
(TRVQA). 
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In a private networking environment, typical network calls consist of an 
originating switch, a tandem switch, and the destination switch, giving a path 
length / = 2. Paths for which / > 3 are rare. Let l = 2 be the default path length. 
An average of 1.51 total RVQ attempts is then required for a blocked call to 
be completed. 


Table 53 gives total RVQ attempts for the default path length / = 2 for the 
North American T1 standard. 


Table 53 
Average total RVQ attempts 


Number of T1 links 


5 6 
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Engineering model 


Table 54 
RVQ parameters 


Parameter Description Default value 


Tx retry timer (sec) 
TGS trunk group size 
L average path length (number of hops) 
TGB trunk group blocking probability 
PRVQP percentage with RVQ privilege 





System parameters 


The system parameters and their default values are listed in Table 53. Several 
other key values can be derived from these parameters. The number of RVQ 
attempts which is required before the busy trunk group is available, RVQA, 
can be found by looking in Table 52. If the average path length L= 2, the total 
number of RVQ attempts required before a path is available can be found in 
Table 54. Otherwise, TRVQA can be calculated using 


RVQA 


TRVQA = —————- 
Q (1-TGB)L-! 
with a default value of 1.51. 


The trunk group call arrival rate is given by 
TGCAR = 18.67 x TGS calls/hr 

or 1325.57 calls/hr in the default case. 

The path blocking probability satisfies 
PB = 1-(1-TGB)-. 


Substituting the default values gives 0.19. 
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The number of RVQ calls per hour (NRVQC) can be calculated by using 
NRVQC = TGCAR x PB x PRVQP/100. 
The default value for NRVQC is 251.86 calls. NRVQC provides a measure 


for the penetration of the RVQ feature. 


Real-time model 


Since basic trunk calls use 111.31 msec real-time and the RVQ setup and 
completion time total 202.38 msec, the incremental real-time required by 
each RVQ call URTRVQ) is 


91.07 + 38.64 x (TRVQA - 1). 
For Tx = 10 seconds and TGS = 71, this value is 110.78 msec. 


Each RVQ call is equivalent to 


IRTRVQ 
78.49 EBC. 


For the default configuration, the value is 1.41 EBC. 


The total incremental real-time requirement is then given by 


IRTRVO pge 


NRY OGAE A 


resulting in 355.12 EBC for the default values. 


Signaling link model 
The incremental traffic on the signaling link is 
192 + 121 x (TRVQA - 1) bytes/RVQ call 
or 253.71 bytes/RVQ call in the default case. To engineer the signaling link, 
assume a 70-30 percent direction split on PRI messages and 30 percent spare 
capacity for traffic peakedness. The incremental bandwidth required for RVQ 


is then 0.002 x [192 + (TRVQA — 1) x 121] bps per RVQ call per hour for a 
total of 


NRVQC x 0.002 x [192 + (TRVQA — 1) x 121] bps 
for NRVQC RVQ calls per hour. The default value is 127.80 bps. 
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Trunking model 
For each trunk group, the incremental traffic is NRVQC x T2/100 CCS which 


gives [((NRVQC x T2 / 100) / TGS] CCS per trunk. The number of additional 
trunks required for RVQ satisfies 


TGS x 18.67 x PB x T2/100 


# additional trunks = 
additional trunks 78 


where 28 CCS is the default busy hour trunk loading value. 


For the default values listed in Table 53, 1.44 additional trunks are required 
due to RVQ. 


Meridian Mail (MM) 
Meridian Mail traffic calculations and capacity table 


Refer to Site and Installation Planning (553-7011-200) for a detailed 
engineering of Meridian Mail, including menu utilization, call duration, 
storage size, disk size, up requirements, and so on. However, for easy 
reference, a simplified table is extracted and included here. 


Each Meridian Mail Module consists of 16 ports which interface with a DTI 
type of loop with 24 ports to provide voice channels. In other words, every 16 
Meridian Mail ports interface with one ENET loop of 30 timeslots. 


As with other traffic calculations, the first step is to determine the average 
holding time of an MM call. This includes both the time the user is logged on 
to MM and the time callers are leaving messages for that user. A typical range 
is 30 to 60 seconds per user depending on the type of application. 


The calling rate per MM registered user is about 10 percent of busy hour calls. 
For example, if a set generates or receives five calls per hour, the MM calls 
would be 0.5 per hour. If there are 2000 MM users in a switch with average 
holding time (AHT) of 60 seconds, its MM traffic would be: 


MM traffic in CCS = 2000 x 0.5 x 60/100 = 600 CCS. 


From Table 55, approximately 23 MM ports are needed for this application. 
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Note that if complicated voice menus are involved for an application, the 
AHT needs to reflect that fact. 


Table 55 
Meridian Mail channel capacity 


No. of channels Capacity in CCS 


54 
157 
273 
522 
651 
782 
915 


4 
8 
12 
20 
24 
28 
32 
36 1049 


56 1729 
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Table 55 
Meridian Mail channel capacity 





The main objective to present Meridian Mail engineering procedure here is to 
show how it fits into the overall Call Center engineering in the later section. 
For a high level MM port requirements estimate, interpolation or 
extrapolation between entries is permitted. 


The major MM parameter which impacts the real-time capacity of a 
co-located Meridian 1 is the type of signaling between the MM processor and 
the Meridian 1 CPU. For locally generated MM calls, CSL and End to End 
signaling have significant capacity effects, and have different real-time 
factors as shown in the real-time calculation worksheet. 
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There are many voice processing features offered with the Meridian Mail 
application, all of which present unique characteristics in MM usage. Each 
specific feature, with varying AHT, will impact the MM port requirement 
differently. This needs to be considered when engineering a specific MM 
application. The following are known applications of the MM feature: Voice 
Mail, Voice Menu, Voice Forms, Auto Attendant, Meridian Interactive Voice 
Response (MIVR), Host Enhanced Voice Processing (HEVP), Network 
Message Service, and Third Party Voice Messaging Systems. 


Meridian Link 


Major Meridian Link applications and their real-time impacts are addressed 
in this section. 


Meridian Link data rate determination 


Although the subject of signaling link engineering is a part of the Meridian 
Link Engineering Guide (553-3203-151), it will be useful to extract some data 
from that document to make this engineering guide more complete, since 
most Call Center applications involve Meridian Link in the configuration. 


Table 56 
Data Link capacity for typical ACD/AML applications 


Link data rate (D) in kbps 64.0 19.2 9.6 4.8 2.4 1.2 





Avg. AML calls/hr 82,202 24,660 12,330 6,115 3,057 1,528 


The data rate chosen for a link, if it is within the limit of the Meridian 1 CPU 
capacity, should correspond to an Application Module Link (AML) call 
capacity value greater than an Meridian 1 is expected to handle. 


As long as there are physical I/O ports in the Meridian 1 to interface the 
AML, there is no practical limit to the number of AML/MLs a system can 
serve. However, the number of calls corresponding to each application must 
be added together to determine whether the total is within the CPU capacity 
of that Meridian 1 system. 


The data link requirement for the CCR application is only 3.2 percent higher 
than for the ML. In other words, the entry in Table 56 should be divided by 
1.032 for the CCR application. For example, at 1200 bps rate, the link can 
handle 1480 CCR calls (= 1528/1.032). 
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When application modules begin using a common base, all applications 
sharing the same AML can add up message link call requirements by using 
the following formula: 


AML calls/hour = (Type 1 calls x 1.0 + Type 2 calls x 1.0 + ...+ CCR 
calls x 1.032) 


Then, check the AML calls/hour against the data rate requirement in the 
above table. At this time the only application with factor other than one is 
CCR. This may change when message usages of more applications are 
studied. 


Incoming AST calls 

In an Associated Telephone (AST), the DN of the set is assigned to be 
controlled by a host. The AST is a set associated with a computer terminal 
through a database stored in the host. A host, alerted by messages of an 
incoming call from the Meridian 1, can bring up customer or sales 
information on the terminal screen while a connection is made to the AST, 
which is frequently an ACD agent. 


Autodialer calls with transfers (Predictive Dialing) 

An Autodialer, controlled by a host, directs the Meridian 1 to make a central 
office (CO) trunk call. When a potential customer answers, the Autodialer 
detects the connection and transfers the call to an agent to answer. The 
average holding time of this type of call is relatively short for the Autodialer 
compare with a conventional call, thus the frequency of calls can be very 
high. The number of calls successfully transferred is normally a small 
percentage (5-20 percent) of total Autodialer calls. 


Customer Controlled Routing 

Customer Controlled Routing (CCR) is an auxiliary product connected to the 
Meridian | via the AML. Depending on the Controlled Direct Number 
(CDN) of the incoming call, CCR can route calls based on a variety of 
attributes, such as Calling Line ID (CLID), Dialed Number Identification 
Service (DNIS), time of call arrival, and the call processing states of the 
ACD-DN (queue size, agent number, and so on). The CCR can put a waiting 
call on a maximum of four queues simultaneously. It also provides the 
flexibility of routing a call to RAN and Music treatments with conditions. 
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Host Enhanced Routing 


The Host Enhanced Routing (HER) feature intercepts an incoming ACD call 
based on the CDN dialed, and gives the call special treatment according to the 
script programmed, such as routing to a specific DN queue, connecting to a 
RAN or Music. It can also make routing decisions based on the conditions of 
agent load and the service criterion. The real-time impacts of basic CCR and 
HER features are similar. Depending on the complexity of scripts, either 
feature can become very sophisticated and real-time extensive. 


Direct Autodialer calls (Preview dialing) 

An Autodialer connected to a 2500 type line card is controlled by a host 
through AML to make calls according to a database in the host. This type of 
call does not involve an ACD agent. The Autodialer either monitors control 
points by dialing these numbers periodically, as used in factory automation 
and sales updates, or is connected to a recording machine to perform customer 
surveys or market research. 


Call Center 


The Call Center is an ACD switch, whose calls are mostly incoming or 
outgoing, with extensive applications features, such as CCR, HER, MIVR, 
HEVP. A port in the Call Center environment, either as an agent set or trunk, 
tends to be more heavily loaded than other types of applications. 


Based on customer application requirements, such as calls processed in a 
busy hour, and feature suite such as RAN, Music, and IVR, the system 
capacity requirements can be calculated. 


ACD 


Automatic Call Distribution (ACD) is an optional feature available with the 
Meridian 1 system. It is used by organizations where the calls received are for 
a service rather than a specific person. 


For basic ACD, incoming calls are handled on a first-come, first-served basis 
and are distributed among the available agents. The agent that has been idle 
the longest is presented with the first call. This ensures an equitable 
distribution of incoming calls among agents. 
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The system is managed or supervised by supervisors who have access to the 
ACD information through a video display terminal. These supervisors deal 
with agent-customer transactions and the distribution of incoming calls 
among agents. 


Many sophisticated control mechanisms have been built on the basic ACD 
features. Various packages of ACD features discussed in this NTP will have 
real-time impact on the Meridian 1 CPU capacity. 


ACD-C1 and C2 packages ACD Management Reporting provides the 
ACD customer with timely and accurate statistics relevant to the ACD 
operation. These statistics form periodic printed reports and ongoing status 
displays so the customer can monitor changing ACD traffic loads and levels 
of service and implement corrective action where required. 


The ACD-C1 package primarily provides status reporting of the system 
through a TTY terminal. To control and alter the configuration of the 
Meridian | system, the ACD-C2 package is required; it provides the load 
management commands. The following is a partial list of functions of a 
supervisor position in the C2 package: 


— assign auto-terminating ACD trunk routes 

— assign priority status to ACD trunks 

— reassign ACD agent positions to other ACD DNs 
— set the timers and routes for first and second RAN 
— define the overflow thresholds 


— specify a night RAN route 


ACD-D package The ACD-D system is designed to serve customers whose 
ACD operation requires sophisticated management reporting and load 
management capabilities. It has an enhanced management display as the 
Meridian 1 is supplemented by an auxiliary data system. The Meridian 1 and 
the auxiliary processor are connected by data links through SDI ports for 
communications. Call processing and service management functions are split 
between the Meridian 1 and the auxiliary processor. 
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ACD-MAX ACD-MAX offers a customer managerial control over the ACD 
operation by providing past performance reporting and current performance 
displays. It is connected through an SDI port to communicate with the 
Meridian 1 CPU. The ACD-MAX feature makes the necessary calculations 
of data received from the Meridian 1 to produce ACD report data for current 
and past performance reports. Every 30 seconds, ACD-MAX< takes the last 10 
minutes of performance data and uses it to generate statistics for the current 
performance displays. The accumulated past performance report data is 
stored on disk every 30 minutes. 


The impact of ACD-MAX calls in the capacity engineering will be in the 
real-time area only. The Meridian MAX is an AP version of the ACD-MAX 
which uses an AP module instead of an HP computer as an auxiliary 
processor. To estimate the impact of MAX on the Meridian 1 CPU, both 
versions can be treated the same. 


NACD 

The majority of tasks in the engineering of Network ACD (NACD) involve 
the design of an NACD routing table and the engineering of overflow traffic. 
The process is too complex to be included here. The engineering procedure 
in this NTP is for single node capacity engineering, which accounts for the 
real-time impact of NACD calls on a switch either as a source node or remote 
target node. Therefore, the overall design of a network is not in the scope of 
this document. 


MIVR 


The Meridian Interactive Voice Response (MIVR) is a Meridian Mail 
application in which a third-party module (Voicetek™ machine) controls the 
operation of an MM through the 9600 baud ACCESS link. The 
communication between the Meridian 1 and MM continues to use the CSL. 
Voice ports required for the MIVR feature are MM ports. 
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In order to provide a balanced configuration among trunks, MIVR ports (or 
MM ports), and agents in the Meridian 1 overall configuration, a brief 
summary of some provisioning requirements are in order: 


1 


Physically, the MIVR port is the same as the MM port, except that it is 
controlled by the MIVR application module through the 9600 baud 
ACCESS link (an asynchronous link). The provisioning of MIVR ports 
is a multiple of 24, just like MM ports. In MIVR release 1, with one 
ACCESS link, 48 MIVR ports are the maximum. In release 2, a second 
ACCESS link will be permitted, which can support another 16 MIVR 
ports. 


The data link, CSL, which provides signaling between the Meridian 1 
and Meridian Mail, is always a 4800 baud synchronous link. 


The distribution of Holding Times (HTs) for MIVR ports are bimodal, 
one short HT for calls that are transferred to live agents and one long HT 
for calls that are served by the MIVR menu. 


The long HT call occupies a trunk circuit just like any other ACD call. 
The short HT call has an incremental impact on trunk occupancy. The 
average HT of a trunk is equal to the sum of the MIVR HT and the agent 
HT. In other words, all transferred MIVR calls have an incremental 
impact on trunking requirements. 


If the default short HT on the MIVR port is 15 seconds, the additional 
CCS to trunk can be estimated as follows: Incremental MIVR CCS to 
trunks = Transferred MIVR calls x 15/100. 


Host Enhanced Voice Processing 

The Host Enhanced Voice Processing (HEVP) feature is similar to the MIVR 
except that the ACCESS link is replaced by a Meridian Mail link, and the 
voice processing is controlled by the Meridian Application Module instead of 
a Voicetek machine. 


An HEVP call involves the AML to control a voice mail treatment; its 
real-time impact on the Meridian 1 is like a combined MM and AML call. 
HEVP real-time impact can be treated like the MIVR. 
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Meridian 911 

The primary difference between the M911 application and other Application 
Module link related incoming ACD calls is the requirement of MF Receivers 
(MER), which interpret digits received from CO through MF trunks for M911 
calls. 


The following procedure should be followed to estimate the MFR 
requirement: 


1 Calculate the number of calls from MF trunks: 


M911 calls = No. of MF trunksx28 x 100/180 = 15.56 x No. of MF 
trunks. 


where the default value of CCS for the trunk is 28 and the average 
holding time is 180 seconds. These numbers should be replaced by 
specific values at your site if they are available. 


2 Calculate MFR traffic: 
MER traffic in CCS = M911 calls x 6/100 


where the ANI digits of 8 were estimated conservatively to hold up a 
receiver for 6 seconds. 


3 Refer to Feature Group D description and operation (553-2901-102) to 
find the requirements of MFRs. For the purpose of estimating MFR 
requirements, the DTR table can be applied. Read the number of DTRs 
(MFRs) corresponding to a CCS entry greater than the above calculated 
CCS value under the column of 6-second holding time. An abbreviated 
table is shown here for simple reference. 


Table 57 
MFR table with 6-second holding time 


No. of MF receivers 10 15 20 


Capacity in CCS 157 300 454 615 779 947 
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RAN and Music 


The RAN trunk can be treated just like a normal trunk. The only potential 
capacity impact is for small systems (options 21 and 61) which may need to 
include RAN trunks in blocking or non-blocking calculations to determine 
the total number of loops or card slots required. Refer to “Service loops and 
circuits” on page 63 to calculate RAN requirements. 


Music in Meridian | is provided by broadcasting a music source from a RAN 
trunk to a conference loop. Therefore, a maximum of 30 users can listen to 
music at one time. If this is not sufficient, an additional conference loop needs 
to be provided for each additional 30 simultaneous music users. 


The conference loop connects to one half of the TDS/CON card. The second 
conference loop, if needed, will take another card and card slot, because it 
cannot be separated from the TDS loop. 


Other features 

Features such as CCR, HER, and Predictive Dialing are as much a Call Center 
feature as an AML one. However, since they were already discussed under 
the Meridian Link umbrella, they will not be repeated here. 


Call Center examples 


Real time factors used in the following examples are based on Release 21 
numbers. The same method and procedures can be applied to later releases 
with new and updated real time factors. 


A basic Call Center with MIVR 


Model: 64 agents, 5 supervisors, 65 PRI trunks, 15 analog trunks. 1600 calls 
per hour required. All incoming calls terminate on 24 MIVR ports. 70 percent 
of calls are transferred to live agents after listening to messages for 15 
seconds, the rest are satisfied with voice menu information. Fifty 
administrative sets (all digital) with 6 CCS per set handle non-ACD calls. 
Meridian Mail is used for administrative traffic. Average holding time is 132 
seconds for all serviced calls. 
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Solution: 
1 Loop requirement 


Table 58 
Worksheet for network loop calculation (example) (Part 1 of 2) 


Column B 
Column A (Loops) 


TDS/CON loops One card (2 loops) per Network Module’ 


BLOCKING: 
ENET loop Admin. sets 50 x6= _300_ CCS 


Non-ACD trunks 
CCS 


Subtotal _300__ + 660 


XNET loop Admin. sets 
Non-ACD trunks 
Subtotal 
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Table 58 
Worksheet for network loop calculation (example) (Part 2 of 2) 


Column B 


Column A (Loops) 


NON_BLOCKING: 
(ENET or XNET) Agent sets 


Supervisor sets 


ACD analog and 
RAN trunks 


Subtotal = 3. (Ny) 
(Nog) 


DTI Trunks = +24 z Nog 
__ 65 


PRI Trunks 


Music ports 


MM/MIVR/HEVP 
ports 


Total loops (Sum of entries under column B) 


Note: All calculations should be rounded up to the next integer. 


“Iterative procedure may be needed, if the number of network modules required was not correctly estimated at 
the outset. 


Conclusion: 
NL <= 26 option 21 
16 < N, <= 32 option 61 
32 < N, <= 160 option 71/81 





553-3001-149 Standard 9.00 October 1997 


Application engineering Page 155 of 294 


TDS/CON loops = 2 one Network Module is initially estimated 
No = [50 x 6/660] = 1 loops for admin. sets 

N; = [(64 +5 + 15)/30]= loops for agent, supervisor sets and trunks 
3 


Nop = [(65 + 2)/24] =3 loops for PRI trunks 
N39 = [24/16] = 2 loops for MM (MIVR) ports 
Total required loops = 2+ 1+3+4+3+42=11 


An option 21 can have up to 26 loops. Therefore, loop capacity in 
option 21 is not a limitation for this configuration. Our initial estimate of 
one Network Module was correct. 


2 Card slot requirement 


Table 59 . 
Worksheet for option 21 card slot calculation (example) 


Column B 
(Slots) 


Music loop One TDS/CON provides one MUSic = __(Ng31) 
QPC414 ENET Blocking Loops 

DTI Loops 

PRI Loops 


Column A (Loop/card) 


MMail Loops 


Subtotal = 5 +2 = 3 
Clock Controller = 1 (If No>0; else = 0 =_ 1 
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Table 59 F 
Worksheet for option 21 card slot calculation (example) 


Column A (Loop/card) pot B 


NT8D04 XNET Blocking Loops 
Nonblocking Loops 
Subtract 4 for NT8D18 NET 


Subtotal = 0 +4 = 0 (Sx) 
NT8D18 NET/DTR = 1 (always equipped) = 1 


I/O cards” Must be >= S, Pe ees 


QPC720 DTI/PRI = 2 X Noif no NT8D35 module; else = 0 = 
Total # of card slots (Sum of entries under column B) =__7_ (Sə 


Conclusion: 
So <= 7 option 21 
7 <S <= 16 option 61 
16 < S, option 71/81 


Note: All calculations should be rounded up to the next integer. A negative loop number should be set to 
zero. 
“Iterative procedure may be needed, if using option 21 or 61 was not clear at the outset. 


“Refer to Table 3 to find the number of I/O cards needed for applications. 
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Without using NT8D35 Network Modules, the PRI ENET alone will 
require seven card slots. Therefore it is not a viable option. 
TDS/CON = 1 

[Noe + Nop + N32)/2] = [5/2] =3 all ENET loops are lumped 


together 
A CC slot needed for option 21 = assumed option 21 is the 
1 candidate 
[N,/4] = [3/4] = 1 XNET loops treated separately 
T/O card slot = 1 one MSDL is enough for MIVR 
and Meridian Mail 


Total slots, S,=1+3+1+1+1=7. 


With a supporting NT8D35 Network Module, the configuration requires 
seven network card slots, which is equal to the maximum number of card 
slots available for an option 21 network module (NT8D11 CE/PE 
Module). Therefore, this configuration is within the limits of an 

option 21. 
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3 Real-time Requirement 


The real-time worksheet used here is slightly modified for Call Center 
applications. An ACD call has the real-time components of a basic call 
(1.0), digital set (0.14), inbound ACD call (0.59). The supervisor set calls 
are added to ACD calls without advanced features, for example, MIVR. 
The administrative set calls (114) are added to basic calls and digital set 
calls. The 20 percent real-time factor for the basic feature package is 
eliminated for special applications like Call Center. 


Real 
Feature Time 
Factor 


Busy hour calls 
500, 2500 set calls 
SL-1 set calls 
Digital set calls 
BRI voice calls 
Data calls 

CPND characters 
CDP calls 

MM (CSL) calls 
MM (EES) calls 
NMS (Main) calls 
NMS (Remote) calls 


Auto Attendant calls 


ACD (Inbound) calls 


ACD (outbound) calls 


ACD-D/MAX calls 
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Feature 


NACD overflowed calls 
Meridian link calls 

MLink status messages 
MLink call transfers 

HER calls 

CCR calls - simple script 
CCR calls - medium script 
CCR calls - complex script 
Predictive dialer 

MIVR without transfer 
MIVR with transfer 


Internal CDR calls 


Outgoing CDR calls 


Incoming CDR calls 
Authorization code calls 
Off-Hook Queuing calls 
Trunk Calls, incoming DTN 
Trunk Calls, incoming DIP 


Trunk Calls, outgoing TIE 
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304 


Real 
Time 
Factor 
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Real 
Feature Time 
Factor 


Trunk Calls, outgoing CO 
RAN messages 

Music 

BARS/NARS calls 

NFCR calls 

DTI calls, incoming 

DTI calls, outgoing 

PRA calls, incoming 
PRA calls, outgoing 

RVQ calls 


Superloop calls 
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Total real-time impact (add up the EBC column) EBC = 5339. 


The user should have calculated the number of calls for each feature 
according to procedures in earlier sections before using the worksheet. 
Calculations of entries in the worksheet are explained by the following 
procedure and equation. 


Fill in the numbers of featured calls applicable to a specific configuration 
in the worksheet. 


Supervisor set calls = 5 x 9.2 = 46 calls 

Adm. set EBC = (50 x 6/1.32) x 0.5 =114 calls 

Basic Call EBC = 1 x (1,600 + 46 + 114) = 1,760 EBC 
Digital set calls = 1760 x 0.14 = 246 EBC 

ACD inbound EBC = (1,600 + 46) x 0.14 = 230 EBC 
MIVR EBC = 1,600 x 0.51 = 816 EBC 

MIVR with transfer EBC = 1,600 x 0.7 x 1.78 = 1994 EBC 


Meridian Mail Call EBC = 114 x 1.05x 0.1 = 12 EBC (assumed 
10 percent of originating/terminating calls being diverted to MMail 
boxes and later retrieved, and the MM is using CSL signaling). 


Out of 1600 calls, about 81 percent (= 65/(65 + 15)) or 1296 calls are 
from PRI trunks, the rest (304) from DTN trunks. 


DTN trunk calls EBC = 304 x 0.11 = 33 

Incoming PRI trunk calls EBC = 648 x (.16) = 104 
Outgoing PRI trunk calls EBC = 648 x (.22) = 143 
Total system EBC = 5,498 

Percent CPU usage = 5,498/5,800 = 94.7% 

Spare CPU capacity = (5,800 — 5,498)/5,800 = 5.3% 


The holding time on MIVR ports will impact the number of MIVR/MM 
ports provided and incoming trunks required; it will not affect the 
loading on the Meridian 1 CPU. 
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4 


Result 


This Call Center can be served by an option 21 Meridian 1. However, the 
CPU has a spare capacity of 5.3 percent when fully loaded. 


To keep this section short, the loop, card slot, and real-time worksheets 
will not be used in the following examples, instead the calculation 
procedure is used. 


A Call Center with Meridian Link and Predictive Dialing 

Model: 23 inbound agents, 4 outbound agents, 3 supervisors. 64 PRI trunks, 
8 analog trunks. Center must support 500 inbound calls and 1500 outbound 
calls per hour. The outbound calls are placed by 30 2500-type lines, 
controlled by a predictive dialing application connected through Meridian 
Link to a host and the Meridian 1. Only 5 percent of calls are answered and 
transferred to a live agent. All inbound calls are controlled by CCR. There are 
50 administrative digital sets with 6 CCS per set. Average holding time per 
call is 150 seconds. Also determine the data link requirements. 


Solution: 


1 


Loop requirement 


TDS/CON loops = 2 the initial estimate of TDS/CON card 
is one 

No = [(50 x 6 + 8 x 28)/875] = 1 8 analog trunks are placed in this loop 

N; = [223 +4 +3 + 30)/30]=2  autodialer ports also require 
nonblocking 

Nop = [(64 + 2)/24] =3 loops for PRI trunks 


Total network loops required = 2 + 1 + 2 + 3 = 8. It is within the 
capability of an option 21. For regular traffic, the CCS can be divided by 
either 660 or 875 CCS to determine the number of loops needed. It 
ultimately is decided by whether IPE or EPE has spare loops for this type 
of traffic without requiring another card slot. In this example, all 
non-PRI/DTI loops are using IPE. 
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Card slot requirement 


We will deal with the case including NT8D35 Network module only, 
since a system without a supporting module can handle no more than two 
PRIs. The calculation for card slots is as follows: 


TDS/CON = 1 assumed one Network Module is enough 

[N>,/2] =2 slots for PRI ENET loops 

CC in option 21 = 1 assumed that the candidate system is an 
option 21 

[(No+ N,)/4] = 1 an IPE superloop is proposed 

T/O card slot = 1 an MSDL is sufficient for DCHI and ESDI 
(CCR) 


S,=1+2+1+1+1=6. the required card slot is equal to 6 (<7), it is 
within the capacity of an option 21. 

Real-time requirement 

Supervisor telephone calls = 3 x 9.2 = 28 

Administrative telephone calls = (50 x 6/1.5) x 0.5 = 100 

Basic Call EBC = (500 + 1,500 + 28 + 100) x 1 = 2,128 EBC 

Digital set EBC = (500 + 28 + 100) x 0.14 = 88 EBC 

Incoming ACD EBC = (500 + 28) x 0.14 = 74 EBC 

CCR EBC = 500 x 1.31 = 655 EBC 

Outgoing ACD EBC = 1,500 x 0.50 = 750 EBC 

Predictive Dialing EBC = 1,500 x 0.05 x 1.72 = 129 EBC 

Outgoing trunk calls EBC = 1500 x 0.03 = 45 EBC; assumed CO trunks 

Incoming PRA EBC = 500 x 0.16 x (64/(64 + 8)) =71 EBC 


Outgoing PRA EBC = 1,500 x 0.22 x (64/(64 + 8)) = 293 EBC; 
PRA calls are proportional to the total trunks. 


Total EBC used = 2,128 + 88 + 74+ 655+ 750 + 129 + 45 + 71 + 293 
= 4,233 


Percent CPU usage = 4,233/5,800 = 73% 
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Data link requirements 


The number of Predictive Dialer calls is 1500, which is less than 1528 
(call capacity of a 1200 baud link). Therefore, the ML requires a data rate 
of 1200 baud. Similarly, the number of CCR calls is less than 1480, 
hence, another link of 1200 baud is sufficient. Note that for systems 
before X11 release 20 for which a common platform for ML and CCR is 
not available, two separate links are needed for this Call Center. With 
co-residency, one link of 2400 baud is able to handle all signaling traffic 
of this application. 


Result 


The required configuration can be handled by an option 21. The 
projected CPU load is 68 percent of the rated capacity. Two data links at 
1200 baud each are needed for ML and CCR applications. 


A Networked Inbound Call Center 

Model: 73 agents, 5 supervisors. 64 PRI trunks, 22 analog trunks. There are 
also 21 TIE trunks to two other centers through NACD interflow. Center must 
support 2000 inbound calls per hour. 25 percent of calls are interflowed to the 
two other centers. There are 48 administrative sets with 6 CCS per set. 
Meridian Mail (8 ports) is used for non-ACD application. A MAX is included 
in the Center, every call has a CDR record and 35 percent of calls served have 
to go through RAN (8 trunks) and Music (30 ports) while queuing. Average 
holding time per call is 120 seconds. 


Solution: 


1 


Loop requirement 


TDS/CON loops = 2 assumed one module (option 21) 

No = [(48 x 6 + 21 x 26)/660] =2 admin. sets and tie trunks are lumped 
together 

N, =[(73 +5 + 22 + 8)/30]=4 loops for agents, analog and RAN 
trunks 

Nop = [(64 + 2)/24] =3 loops for PRI trunks 

N31 = [30/30] = 1 loops for Music 

N32 = [8/24] = 1 loops for Meridian Mail ports 


Total loops required =2 +2 +4+3+1+1=13 


The loop requirement can be met by an option 21. 
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2 Card slot requirement 


Again, with PRI trunks, we will consider only the case with the NT8D35 
Network Module included. 


TDS/CON = 1 

[No/2] = 2/2 = 1 ENET loop is proposed for regular 
traffic 

[N,/4] = 4/4 =1 a full superloop for high traffic ports 

[Nap + N32)/2] = [(3 + 1)/2] =2_ slots for EPE loops (PRI and Meridian 
Mail) 

CC in option 21 = 1 tentatively assumed using option 21 

Card for Music = 1 the CON of the second TDS/CON for 
Music 

T/O ports slots = 2 2 MSDL for 2 DCHIs, Meridian Mail, 


Meridian MAX, and CDR 
Se=1+1+1+2+1+1+2=9 


This card slot requirement exceeds the capacity of an option 21. 
Therefore, an option 61 is needed. 
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3 Real-time requirement 
Supervisor telephone calls = 5 x 9.2 = 46 
Administrative telephone calls = 48 x 6/1.2 x 0.5 = 120 
Basic Call EBC = (2,000 + 46 + 120) x 1 = 2166 EBC 
Digital set EBC = (2,000 + 46 + 120) x 0.14 = 303 EBC 
Incoming ACD EBC = (2,000 + 46) x 0.14 = 286 EBC 
NACD Overflowed Call EBC = 2,000 x 0.25 x 2.89 = 1445 EBC 


RAN/MUS traffic in EBC = 2,000 x (1 — 0.25) x 0.35 x (0.37 + 0.46) 
= 436 EBC 


MAX EBC = 2,000 x 0.81 = 1,620 EBC 
CDR Record (inc.) EBC = 2,000 x 1.25 = 2,500 EBC 


Meridian Mail Call EBC = 120 x 1.05 x 0.1 = 13 EBC (assumed 
10 percent of non-ACD calls being diverted to MMail boxes and with 
CSL signaling) 


Incoming DTN trunk EBC = 2,046 x 0.11 = 225 EBC 
Outgoing tie trunk EBC = 2,000 x 0.25 x 0.15 = 75 EBC 
Incoming PRA calls EBC=2,046 x (64/(64 + 22)) x (-0.16) = 244 EBC 


Total EBC used = 2,166 + 303 + 286 + 1445 + 436+ 1,620 + 2,500 + 13+ 
225 + 75 + 244 = 9,313 EBC 


Percent CPU usage = 9,313/22,500 = 41% 


Since we are using option 61 due to the card slot requirement, the EBC 
of 22,500 from Real-time Capacity Table for option 61 is used. Note that 
even if there is no card slot limitation, the number of required EBC 
(9,313) exceeds the option 21’s capacity of 5,800 EBC. The system will 
require a larger system than an option 21. 


4 Result 


The required configuration exceeds the capacity of an option 21 in both 
card slot and real-time limitations. Therefore, an option 61 is required 
which will provide plenty of spare capacity for future growth. 
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Inbound Call Center with MIVR 

A Call Center with 285 agents, 30 supervisors, 565 trunks of which 358 are 
digital. All calls go to IVR first. Meridian IVR has 5 ACD DNs, 64 agents 
(simultaneous sessions), and is connected through cluster controllers to an 
IBM mainframe. Assume that 80 percent of calls are transferred to live 
agents, 20 percent remain in IVR. Assume average holding time in MIVR for 
transferred calls is 10 seconds, and held calls is 120 seconds. Average live 
agent ACD call holding time is 132 seconds. The Center must support 7,000 
calls per hour on the ACD side. 


Assume that CCR controls 70 percent of the calls transferred to live agents 
from the MIVR, with the rest coming straight into ACD DNs. There are also 
100 administrative sets, with an average load of 6 CCS per set for both 
internal and external calls. Meridian Mail is used for internal and external 
purposes by administrative telephone calls, which share ports with the MIVR. 


Solution: 


1 Loop requirement: 


TDS/CON loops = 6 3 Network Modules are needed; this 
number is re-calculated after the first 
NL had been obtained 

No = [(100 x 6)/660] = 1 loops for admin. telephones 

N; = [(285 +30 + 207)/30] = 18 loops for agents, supervisors, analog 
trunks 

Nap = [(358 + 2)/24] = 15 loops for PRI trunks 

N32 = [64/16] = 4 loops for MIVR ports; the MIVR R1 


has a capacity of 48 ports, R2 will have 
64 





N =6+14+18+15+4=44 43 loops are required for this 
application 


The configuration requires an option 71 or 81 with at least two network 


groups (or three Network Modules). Because an option 71/81 is to be 
used, no checking on the card slot limitation is needed. 
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2 Real-time requirement: 


Total calls to MIVR and the system = 565 x 15.6 = 8814 calls/hour 
(assumed 15.6 calls per trunk). In this example, the offered calls to the 
system are defined by the number of fully loaded trunks, not calls 
handled by agents and supervisors. Since calls from trunks should 
include everything, the supervisor sets will not add additional calls to the 
total trunk calls. 


Admin set calls = 100 x 6 x 0.5 x 100/120 = 250 (120 seconds HT for 
admin sets) 


Basic call EBC = (8,814 + 250) x 1 = 9,064 

Digital set calls = 9,064 x 0.14 = 1,269 

ACD EBC = 8,814 x 0.14 = 1,234 

MIVR EBC = 8,814 x 0.51 = 4,495 

MIVR with transfer EBC = (8,814 x 0.8) x 1.78 = 12,551 
CCR calls EBC = (8,814 x 0.8) x 0.7 x 1.31 = 6,466 


EBC for MMail = 250 x 0.1 x 1.05 = 26 (10 percent of admin calls go to 
MM) 


RAN/MUS EBC = (8814 x 0.8) x 0.7 x 0.2 x 0.83 = 819 (20 percent of 
CCR calls require RAN/MUS) 


Incoming trunk calls EBC = 8814 x 0.11 = 970 
PRA trunk calls EBC = 8814 x (358/565) x (0.16) = 894 


Total system EBC = 9,064 + 1,269 + 1,234+ 4,495 + 12,551 + 6,466 + 
26+ 819 + 970 + 894 = 37,788 


This EBC exceeds the CPU capacity of an option 71. An option 
81/61C/51C is required. 


Percent CPU utilization (option 81/61C/51C) = 37,788/49,400 = 76% 
3 Result 


This configuration exceeds option 61 in physical requirement, and 
option 71 in real-time capacity (22,500). However, it can be handled by 
an option 81 with about 76 percent loading on the CPU. 
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A Call Center with HEVP 

Model: A Call Center with 480 agents, 50 supervisors, 760 trunks of which 

510 are PRI. 20 percent of all calls go to HEVP CDN first, half of them use 
voice menu for 90 seconds and disconnect; the other half will transfer to live 
agents after using voice ports for 20 seconds and be served. 60 percent of the 
remaining total calls will terminate on ACD DNs, the remaining 40 percent 
will terminate on CCR CDNs. Assume that the average service time of a call 
by live agent is 180 seconds regardless of its source. Although there are some 
shorter calls, because of queues, average holding time per trunk is also 180 

seconds. 


Questions to be answered: 

— ls this configuration within the loop capacity of a Meridian 1? 
— How many incoming calls are to be processed in this scenario? 
— How many MM ports are needed to serve this HEVP? 


— Which option of Meridian 1 is needed to handle this configuration and at 
what level of CPU load? 


— What data rates are required at various signaling links? 


The block diagram of a typical HEVP application is given in Figure 10. Note 
that a common platform for CCR and HEVP applications is not available 
before X11 release 20. 
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Figure 10 
A simplified HEVP configuration 
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Solution: This scenario is simplified to concentrate on HEVP related issues 
only. Other applications demonstrated earlier can be superimposed on the 
HEVP feature to give a complete picture of a Call Center application. 


We will deal with the questions one by one: 


1 


Loop capacity 


The information to determine loop requirement is not complete until we 
know how many voice ports on the MM are needed. Item 3 in this 
solution text indicates 44 ports are needed. 


The required number of loops are: 


TDS/CON loops = 8 re-calculated after initial 
estimate 

N; = [{480 + 50 + (760 — 510)}/30] = 26 either IPE or EPE will do 

Nop = [(510 + 2)/24] = 22 card slots for PRI loops 

N32 = [44/16] =3 Meridian Mail ports based 


on HEVP port calculation 
(item 3 below) 


NL =8 + 26 +224+3=59 


Physically, the system has to be a 2-group (4 Network Modules) 
option 71 or 81. There is no need to check card slot limitations for a large 
system. 


Total system calls 


The default CCS per trunk is 28, therefore, calls per trunk is 15.56 
(= 28/1.8). 


Total incoming ACD calls/hour = 760 x 15.56 = 11,826. 
HEVP CDN calls = 11,826 x 0.2 = 2365 
HEVP calls with transfer = 2365 x 0.5 = 1183 
CCR CDN calls = 11,826 x (1 — 0.2) x (1 — 0.6) = 3784 
HEVP ports 
Traffic calculation: 
CCS = (2369 x 0.5 x 90 + 2369 x 0.5 x 20)/100 = 1066 + 237 = 1303 
From Table 55, 44 voice ports are needed to handle 1303 CCS. 
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4 CPU loading 
Basic Call EBC = 1 x 11,826 = 11,826 
Digital set calls EBC = 11,826 x 0.14 = 1,656 (assumed all digital) 
ACD EBC = 11,826 x 0.14 = 1,656 
HEVP EBC = 2,365 x 0.51 = 1206 (used MIVR factors for HEVP) 
HEVP with transfer EBC = 1,183 x 1.78 = 2,106 
CCR EBC = 3,784 x 1.31 = 4,957 
Incoming trunk calls EBC = 11,826 x 0.11 = 1,301 
PRA calls EBC = 11,826 x (510/760) x (0.16) = 1,270 


Total system EBC = 11,826 + 1,656 + 1,656 + 1,206 + 2,106 + 4,957 + 
1,301 + 1,270 = 25,978 


Percent CPU usage = 25,978 / 22,500 = 115% 


Option 71 with call capacity of 22,500 EBC (from Table 14) will not be 
able to handle this configuration. 


5 Signaling link requirements 


According to Table 56, 3,784 CCR calls require a data link of 4800 baud. 
2365 HEVP calls need a data link of 2400 baud. The ACCESS link 
(Meridian Mail Link) is a fixed 9600 baud link. The CSL link is also a 
fixed 4800 baud link. 


Configuration Parameters 


Design parameters are constraints on the system established by design 
decisions and enforced by software checks. A complete list is given in the 
Appendix, with default values, maximums and minimums, where applicable. 
Although defaults are provided in the factory installed database, the value of 
some of these parameters are to be set manually, through the O0A&M 
interface, to reflect the actual needs of the customer’s application. 


For guidelines on how to determine appropriate parameter values for call 
registers, I/O buffers, and so on, see “Mass storage size” on page 115. 
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